home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP053192.ARJ / 05-31-92.TPC
Text File  |  1992-05-31  |  65KB  |  1,936 lines
  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       01-01-00 00:00:00
  6. From       
  7. To         
  8. Subject    
  9.  
  10.  
  11. --- WM v2.01/92-0100
  12.  * Origin: A.C.E. of Spades (615)383-4381 The B.A.N. board (1:116/33)
  13.  * Tossed by SFToss v1.00b on 92/04/09  12:01:00
  14.  
  15. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  16.  
  17. Conference 4
  18. Date       05-24-92 04:50:49
  19. From       Trevor Carlsen
  20. To         Gordon Tackett
  21. Subject    Running Bat files from Pascal
  22.  
  23.  
  24.  
  25.  GT> EXEC('C:\COMMAND.COM','/cFILE.BAT');
  26.  
  27.  > What if he doesn't have command.com in the root
  28.  > directory? Or worse, what if he doesn't have
  29.  > command.com?
  30.  > :-)
  31.  
  32.  GT>  Ok TeeCee - he did say .bat files if you know of another dos
  33.  GT>  shell that will run .bat files let me know! As for the root
  34.  GT>  directory...well you got me there but this was a quick help
  35.  GT>  messages so the real help line shoule be:
  36.  
  37. There are many command processors available that don't call themselves command.c
  38. m.
  39.  
  40.  GT> EXEC(GETENV('COMSPEC'),'/cFILE.BAT');
  41.  
  42.  GT> This better :-)
  43.  
  44. Yep! Now it doesn't matter where the CP is or what it is called. (glad you
  45. noticed my smiley.)
  46.  
  47.  GT> And on a totaly different subject...thanks for the netmail
  48.  GT> reply so quick! 4.5 hours round trip is faster and cheaper
  49.  GT> than snail mail to downunder from here!
  50.  
  51. It helps when we are 14 hours ahead of you! :-)
  52.  
  53. TeeCee
  54.  
  55. --- TC-ED   v2.01  
  56.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  57.  * Tossed by SFToss v1.00b on 92/05/24  14:54:16
  58.  
  59. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  60.  
  61. Conference 4
  62. Date       05-24-92 04:34:48
  63. From       Trevor Carlsen
  64. To         John Jacobs
  65. Subject    Interrupts And You
  66.  
  67.  
  68.  
  69.  JJ> I'm looking for a generic example of how to make a procedure
  70.  JJ> get executed once during each clock interrupt (or timer,
  71.  JJ> whatever).
  72.  
  73.  JJ> I'm not talking a TSR, but just something within a TP
  74.  JJ> program, such as updating a status bar for example.
  75.  
  76.  JJ> Everything I've tried has crashed like there's no tomorrow
  77.  JJ> (maybe there isn't).
  78.  
  79.  JJ> It shouldn't be that difficult...
  80.  
  81. It isn't... *provided* that you follow certain strict rules.  The main one
  82. is that you do not uses any DOS service.  This bars things like write/writeln,
  83. GetTime, etc. as they make use of DOS to do their thing.
  84.  
  85. Another thing is to turn off interrupts when you enter your routine and turn
  86. them back on just before you leave it.  Obviously any routine written must
  87. be capable of executing before another interrupt is expected.
  88.  
  89. Do not forget to call the previous routine that serviced that interrupt and
  90. finally make sure you write an exit procedure that restores any hooked vectors
  91. on program termination.  This is most important.
  92.  
  93. TeeCee
  94.  
  95.  
  96.  
  97. --- TC-ED   v2.01  
  98.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  99.  * Tossed by SFToss v1.00b on 92/05/24  14:54:16
  100.  
  101. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  102.  
  103. Conference 4
  104. Date       05-24-92 04:55:47
  105. From       Trevor Carlsen
  106. To         Jim Zerbe
  107. Subject    Program
  108.  
  109.  
  110.  
  111.  JZ>    I am just getting into Pascal and seem to have bitten off
  112.  JZ> more then I can chew.  I  have started two programs and seem
  113.  JZ> to have come across a little problem.
  114.  
  115.  JZ>    1).  The SEEK command.  I have created a TYPE file
  116.  JZ> listing of file names and descriptions of a CD-Rom disk I've
  117.  JZ> also created a isting all files in each sub directory.  Now
  118.  JZ> I need to pull the file name from each  up and search the
  119.  JZ> description for he name to grab the description.
  120.  
  121. The help screens contain an example of how to use this *procedure*. (There
  122. is no such thing as a command in TP.)  If you are in the IDE place your cursor
  123. on the word seek and press Ctrl-F1.  I suspect though, that something more
  124. fundamental may be the problem.  Without seeing any example it is hard to
  125. help.  Seek does not work on text files.  Let's see a short abbreviated example.
  126.  
  127.  JZ>     2). The GETENV command.  To Set the DOS PATH command
  128.  JZ> from the Autoexec.Bat file to the program.
  129.  
  130. The GetEnv *function* returns the string associated with the environment variabl
  131.  you specify.  It does not set the variable.
  132.  
  133. TeeCee
  134.  
  135. --- TC-ED   v2.01  
  136.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  137.  * Tossed by SFToss v1.00b on 92/05/24  14:54:16
  138.  
  139. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  140.  
  141. Conference 4
  142. Date       05-24-92 05:04:00
  143. From       Trevor Carlsen
  144. To         Patrick Riley
  145. Subject    Turbo 6
  146.  
  147.  
  148.  
  149.  PR>  I was looking at the message list on here and it seems
  150.  PR> there is a TURBO 6.0.  Right now I have TURBO 5.0, would it
  151.  PR> be worth it to buy TURBO 6.0.  What are the improvements?
  152.  
  153. It depends on what you want to do.  The major difference between 5.0 and 6.0
  154. is the addition of OOP capabilities to the language. Other enhancements are -
  155.  
  156.  
  157.  - An object oriented application framework called Turbo Vision.  This
  158.    is a large library of tools to build an event driven OOP application 
  159.    shell.  A big learn needed but very powerful.
  160.  - A built in in-line assembler (BASM)
  161.  - 80286 code generation
  162.  - A new heap manager (that breaks a lot of code written for TP4/5 heap)
  163.  - Extended syntax (use a function in the same way as a procedure)
  164.  - Address references in typed constants
  165.  - Link in initialised data from object files
  166.  
  167. If you use the IDE then there are MAJOR improvements
  168.  
  169.  - Multiple overlapping windows
  170.  - Mouse support
  171.  - Multiple files up to 1 meg
  172.  - A much improved IDE debugger
  173.  
  174. TeeCee
  175.  
  176. --- TC-ED   v2.01  
  177.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  178.  * Tossed by SFToss v1.00b on 92/05/24  14:54:16
  179.  
  180. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  181.  
  182. Conference 4
  183. Date       05-24-92 09:14:42
  184. From       Dj Murdoch
  185. To         Clay Jones
  186. Subject    Re: Streams
  187.  
  188.   CJ> Gentlemen, I have been exploring the possibilities of TVision lately and
  189.  CJ> have been having a lot of fun. But there is one entire facet of it that
  190.  CJ> has me completely stumped: Streams.
  191.  CJ> Is there anyone out there who can shed just a little light on this
  192.  CJ> subject for me?  Thank you very much for your indulgence...
  193.  
  194. Streams are very simple at heart.  The key to understanding them is to completel
  195.  ignore the manual :-).  The manual says:
  196.  
  197. "Streams handle I/O on the object level rather than the data level."
  198.  
  199. This is very misleading.  Streams handle I/O on the data level, and *also*
  200. on the object level.  Understand the basic data level first, and the object
  201. level understanding will follow.  The rest of the chapter deals with the object
  202. level, so I'd skip it.
  203.  
  204. The truth is that streams are general binary files.  They're very easy to
  205. work with - much easier than untyped files in TP.   If you want to read a
  206. record from a file, you just read it using:
  207.  
  208.   var
  209.     S : TDosStream;
  210.     
  211.   S.init('myfile.dat',stOpenRead);  { Open it for read-only access. }
  212.  
  213.   S.Read(myrec,sizeof(myrec));
  214.  
  215. That's it!  Much simpler and more foolproof than using untyped files.  
  216.  
  217. When you want to move on to doing object level I/O on streams, you just need
  218. to learn one more thing:  the Put method writes a key to the stream before
  219. it asks your object to write out its data, and the Get method reads the key
  220. and uses it to decide which type of object it should try to load.  
  221.  
  222. I'd recommend spending some time playing with streams as binary files to get
  223. a feeling for them.  Then re-read the manual, when you want to find out the
  224. details of how Put and Get work.
  225.  
  226. You might want to get a copy of my Streams unit (STREAM13.ZIP, 60K) from a
  227. PDN Pascal node (e.g. my bossnode, 1:221/177, 1-519-578-9314, 9600, HST, V42b).
  228. It gives about 100K of source code for various special kinds of streams, but
  229. never uses Put or Get.
  230.  
  231. If you have any specific questions, I'll try to answer them. 
  232.  
  233. --- Msg V3.2
  234.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  235.  * Tossed by SFToss v1.00b on 92/05/25  07:11:46
  236.  
  237. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  238.  
  239. Conference 4
  240. Date       05-24-92 09:30:56
  241. From       Dj Murdoch
  242. To         Lawrence Mcalpin
  243. Subject    Re: Borland, OS/2 2.0, and you
  244.  
  245.   LM> And your programs can use more memory, far more than the 
  246.  LM> 640k limit that DOS gives you.  The closest thing to 
  247.  LM> breaking the 640k limit that Microsoft will be making for 
  248.  LM> a long time is Windows NT, which will have the exact 
  249.  LM> _same_ requirements as OS/2 has, but will be slower, and 
  250.  LM> won't handle virtual DOS machines as well as OS/2 does.
  251.  
  252. That's pretty misleading.  TP for Windows programs can easily get multiple
  253. megabytes of heap space - all free extended memory in standard mode, additional
  254. virtual memory from the disk in 386 enhanced mode.  
  255.  
  256. OS/2 2.0 is technically much better than Windows, but it still can't do any
  257. better than Windows on memory for TP.  That'll require a change to TP, and
  258. while Borland has announced plans for a 32 bit C++, they haven't said anything
  259. about a 32 bit TP.  (The announcement of a DOS extended Borland Pascal doesn't
  260. count, because it wasn't clear about whether BP would run in 16 bit or 32
  261. bit protected mode.)
  262.  
  263.  
  264. --- Msg V3.2
  265.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  266.  * Tossed by SFToss v1.00b on 92/05/25  07:11:46
  267.  
  268. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  269.  
  270. Conference 4
  271. Date       05-24-92 00:09:23
  272. From       Mark Ouellet
  273. To         Ken Burrows
  274. Subject    Got your Netmail, couldn't connect
  275.  
  276.  
  277. Hi Ken,
  278.         Sorry if I didn't reply but I actually tried 2 or 3
  279. times to send you a reply via NetMail, with no success. Each
  280. attempt was terminated on error.
  281.  
  282.         Anyways, sorry but no, I don't have any Net routines
  283. in TP. I replied to the File lcking thread because
  284. eventhough our application is written in dBase IV, Network
  285. record locking is still the same. One must lock records, not
  286. whole files or Networking makes no sense if you can't work
  287. on the same file simultaneously with someone else.
  288.  
  289.         I know there are a few TP Novell API units floating
  290. around in PDN, you might want to have a look there.
  291.  
  292.         Best regards,
  293.         Mark Ouellet.
  294.  
  295.  
  296.  
  297. --- ME2
  298.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  299.  * Tossed by SFToss v1.00b on 92/05/25  13:44:23
  300.  
  301. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  302.  
  303. Conference 4
  304. Date       05-24-92 00:56:44
  305. From       Mark Ouellet
  306. To         Mike O'Toole
  307. Subject    Netmailing
  308.  
  309.  
  310. Hi Mike,
  311.         I haven't forgotten you but I tried to Netmail you
  312. and your system not being Continuous Mail capable makes it
  313. hard.
  314.  
  315. Isn't there a CM FidoNet node where I can NetMail you???
  316.  
  317.         Best regards,
  318.         Mark Ouellet.
  319.  
  320.  
  321.  
  322. --- ME2
  323.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  324.  * Tossed by SFToss v1.00b on 92/05/25  13:44:23
  325.  
  326. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  327.  
  328. Conference 4
  329. Date       05-24-92 23:07:12
  330. From       Trevor Carlsen
  331. To         James Chambers
  332. Subject    Re: Keyinput.pas
  333.  
  334.  
  335.  
  336.  JC>         I have been playing around with your keyinput unit and am 
  337.  JC> overlooking
  338.  JC> something.  Whenever I try to compile a program, the compiler stops on 
  339.  
  340.  JC> the
  341.  JC> color argument in the line and gives me an error.  Would it be 
  342.  JC> possible for
  343.  JC> you to whip together about a five line example program so I can see 
  344.  JC> what I am
  345.  JC> missing?
  346.  
  347. I presume you are trying it with the example usage I included.  The variable
  348. LtGrayOnBlue comes from a unit called Colordef included with the Turbo Power
  349. products.  Try to compile this -
  350.  
  351. uses keyinput;
  352.  
  353. const
  354.   LtGrayOnBlue = $17;
  355. var
  356.   st : string;
  357.  
  358. begin
  359.   st := '';
  360.   writeln('<Escape> quits');
  361.   repeat
  362.     st := ReadStr(20,'Enter a 20 character string: ',
  363.                   LtGrayOnBlue,st,AlphaNumeric);
  364.   until st[1] = #27;
  365. end.
  366.  
  367.  
  368. TeeCee
  369.  
  370.  
  371. --- TC-ED   v2.01  
  372.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  373.  * Tossed by SFToss v1.00b on 92/05/25  18:29:57
  374.  
  375. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  376.  
  377. Conference 4
  378. Date       05-25-92 19:32:00
  379. From       Norbert Igl
  380. To         Gerald Gutierrez
  381. Subject    Detecting ANSI ?
  382.  
  383.  
  384.  
  385.  
  386.  >> Function AnsiSysInstalled: boolean;
  387.  > I wasn't aware that there was an ANSI detection function. Is this
  388.  > standard ? ( ie: does it support all ansi drivers ? )
  389.  
  390.   Well, it depends on the particular ANSI-Driver.....
  391.   If it's "compatible" with ANSI.SYS, it will install
  392.   this multiplex-function. If not....(:-(
  393.  
  394. Bye from Germany, Norbert
  395.  
  396. ---
  397.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  398.  * Tossed by SFToss v1.00b on 92/05/26  07:25:00
  399.  
  400. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  401.  
  402. Conference 4
  403. Date       05-25-92 08:12:16
  404. From       Dj Murdoch
  405. To         KEVIN PARADINE
  406. Subject    Re: FEATURES LACKING IN T
  407.  
  408.    >You only change the segment registers once at the start, 
  409.   > and restore them
  410.   >at the end.  This lets you move 64K with only one change to the segment
  411.   >registers.  Unless you're talking about moving tiny 
  412.   > blocks many times, it's
  413.   >not significant.
  414.  
  415.  KP> How do you go about doing that?  You are using MOV, 
  416.  KP> correct?  Try an assembler guide regarding segment overrides.
  417.  
  418. I don't quite know what you're asking me to do.  I wouldn't use MOV to move
  419. large blocks; the string instructions are much better, and behave just as
  420. I said.  What's the exact problem you're trying to solve?
  421.  
  422. --- Msg V3.2
  423.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  424.  * Tossed by SFToss v1.00b on 92/05/26  11:17:24
  425.  
  426. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  427.  
  428. Conference 4
  429. Date       05-25-92 08:25:54
  430. From       Dj Murdoch
  431. To         Frank Rachel
  432. Subject    Re: General program question
  433.  
  434.   FR> I am about to start working on a project, which I would like to write in
  435.  
  436.  FR> Pascal.  In short, it is a program for marching band/drum corps drill
  437.  FR> writers.  the screen would be a picture of a football field, where each
  438.  FR> person (up to 128) would be a dot.  I would like it so that the program
  439.  FR> will in essence, 'run through' the show, having the dots move around on
  440.  
  441.  FR> the screen, you you can get a top view of what the marching would look
  442.  FR> like.  I would also like to have the dots connected where necesary to
  443.  FR> get a better picture.  At this moment, I need to know if the BGI stuff
  444.  FR> will be fast enough to move 128 dots, connected together in different
  445.  FR> patterns around the screen.
  446.  
  447. I don't know the answer to your question, but what I'd recommend is that you
  448. go ahead and try it with the BGI.  Isolate all of you screen updates into
  449. one or a few routines; later, if you find BGI is too slow, you'll be able
  450. to drop in a replacement graphics system with only minimal changes to your
  451. program.
  452.  
  453. One replacement system is called Acromole; it can easily show a spinning cloud
  454. of 1000 points or several hundred lines with very smooth motion.  It's no
  455. good at bitmaps, though.  It's written by Acrobits, whose phone number a few
  456. years ago was 1-800-ACR-OBIT; they've moved though, and may have changed the
  457. number.
  458.  
  459. --- Msg V3.2
  460.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  461.  * Tossed by SFToss v1.00b on 92/05/26  11:17:25
  462.  
  463. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  464.  
  465. Conference 4
  466. Date       05-25-92 16:37:42
  467. From       Trevor Carlsen
  468. To         Brian Stark
  469. Subject    Re: Unix Style timestamp 
  470.  
  471.  
  472.  
  473.  BS> ... The unit was developed to help me in writing programs 
  474.  BS> for the Opus-Cbcs system. Now you are really confusing me,
  475.  BS> were the comments a suggestion, or a correction?? The only harsh 
  476.  BS> criticism I have received ...
  477.  
  478. My original comments were a suggestion, as the original function to determine
  479. the time zone was very unwieldy.  Later, when you posted a "correction" to
  480. the leap year algorithm, I posted a correction.  By and large it was a good unit.
  481.  
  482.  
  483. TeeCee
  484.  
  485. --- TC-ED   v2.01  
  486.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  487.  * Tossed by SFToss v1.00b on 92/05/26  18:10:28
  488.  
  489. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  490.  
  491. Conference 4
  492. Date       05-26-92 07:40:53
  493. From       Dj Murdoch
  494. To         Kenneth Otto
  495. Subject    Re: Turbo 6
  496.  
  497.   KO> ver 5 produces smaller code for   ver 6 produces bigger code for
  498.  KO> small projects                    small projects
  499.  
  500. I'd agree with all your other comparisons, but this one hasn't been my experienc
  501. .  Could you say what it's based on?
  502.  
  503. --- Msg V3.2
  504.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  505.  * Tossed by SFToss v1.00b on 92/05/27  13:08:18
  506.  
  507. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  508.  
  509. Conference 4
  510. Date       05-26-92 07:45:35
  511. From       Dj Murdoch
  512. To         Lior Tsoref
  513. Subject    Re: Object Professional and true EGA/VGA
  514.  
  515.   LT> Hi.
  516.  
  517.  LT> This question is for Turbo Pascal users who use 
  518.  LT> TurboPower's ObjectProfessional.
  519.  LT> Does anyone have any idea how to convert OpMouse unit into displaying true
  520.  
  521.  LT> EGA/VGA mouse cursor ? (The mouse low level routines are 
  522.  LT> supplied in OBJ format)
  523.  
  524. They're also supplied in .ASM format, so you could change them if you wanted.
  525.  But remember, OPro is a text mode library, so a graphics mode mouse cursor
  526. is going to be a lot of work.  Take a look at MOUxxx.ZIP, a library in C and
  527. TP6 which fakes a graphics cursor by changing character maps on the fly. 
  528. It should be available on any PDN Pascal node; the last version I hatched
  529. was MOU105.ZIP, but the author may have updated it since then.
  530.  
  531. One PDN Pascal node you can try if you don't find anything closer is my bossnode
  532.  1:221/177, 1-519-578-9314,9600,HST.
  533.  
  534.  
  535. --- Msg V3.2
  536.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  537.  * Tossed by SFToss v1.00b on 92/05/27  13:08:18
  538.  
  539. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  540.  
  541. Conference 4
  542. Date       05-26-92 08:05:16
  543. From       Dj Murdoch
  544. To         All
  545. Subject    I'm changing my address
  546.  
  547.  I'll be moving in about 3 1/2 weeks, and will be changing my netmail address
  548. to 1:249/99.5.  If you've got any netmail for me, you might as well send it
  549. to the new address - I poll a few times a week, and netmail to my current
  550. address has been pretty unreliable lately.
  551.  
  552. --- Msg V3.2
  553.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  554.  * Tossed by SFToss v1.00b on 92/05/27  13:08:18
  555.  
  556. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  557.  
  558. Conference 4
  559. Date       05-26-92 19:02:49
  560. From       Mark Ouellet
  561. To         Dale Barnes
  562. Subject    Re: e-mail
  563.  
  564.  
  565.     On 15 May 92, you, Dale Barnes, of 1:3601/14.20 wrote...
  566.  
  567.  >>         Take a look at.... OOPS MEMORY LAPS.. what's that
  568.  >> darn flying horse's name..Oh yeah, PEGASUS, full E-Mail
  569.  >> system for NetWare with file enclosure etc... and it's
  570.  >> free-ware.
  571.  
  572.  DB> Hello Mark,
  573.  DB> 
  574.  DB> Do you have a net/node or know where one may obtain a current version of 
  575.  
  576.  DB> this product?
  577.  
  578. Dale,
  579.         Can't remember the node where I got it but here is
  580. the order form for Pegasus 2.1 (Note the registration form
  581. is to obtain PRINTED MANUALS, you do not need to register if
  582. you don't need the fancy manual. The software is FREEWARE,
  583. he makes money by selling printed manuals but he does state
  584. it is not an obligation)
  585.  
  586. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- CUT -=-=-=-=-=-=-=-=-=-=-=-=-
  587.  
  588.                  +----------------------------------+
  589.                  |        O R D E R   F O R M       |
  590.                  |     for Pegasus Mail Manuals     |
  591.                  +----------------------------------+
  592.  
  593.  
  594. Ship to:                            Bill to: 
  595.  
  596. [                            ]      [                               ]
  597. [                            ]      [                               ]
  598. [                            ]      [                               ]
  599. [                            ]      [                               ]
  600. [                            ]      [                               ]
  601.  
  602.  
  603. Please supply the following items:
  604.  
  605. ----------------------------------------------------------------------
  606.  
  607. [  ] Manuals for Pegasus Mail @ US$100 (includes license
  608.      to make up to five copies of each copy ordered for 
  609.      internal use). . . . . . . . . . . . . . . . . . . . US$[       ]
  610.  
  611.  
  612. [  ] Site-licensed manuals for Pegasus Mail @ US$250 
  613.      (allows unlimited copying of the manual for internal
  614.      use in one site, where a site is defined as the 
  615.      extent of an organization in one city. . . . . . . . US$[       ]
  616.  
  617.  
  618. Shipping via first-class airmail is included in the price of either 
  619. type of manual.
  620.  
  621. ----------------------------------------------------------------------
  622.  
  623.  
  624. Ordering instructions:  Please complete this form, and send it via
  625. airmail with your cheque or PO to:  
  626.  
  627.     Pegasus Mail, c/- David Harris, 
  628.     P.O. Box 5451, Dunedin,
  629.     New Zealand.
  630.  
  631.     or e-mail it and the PO number to:
  632.       david@otago.ac.nz (on CompuServe, internet:david@otago.ac.nz)
  633.  
  634. Purchase orders are accepted from any educational institution, or 
  635. any company with paid-up capital of $30,000 or more: please enclose 
  636. purchase order with this order form. If you require a pro-forma 
  637. invoice prior to the issue of a purchase order, please send details
  638. to the postal or e-mail address shown above.
  639.  
  640. =-=-=-=-=-=-=-=-=-= CUT =-=-=-=-=-=-=-=-=-=-
  641.  
  642.         Hope this helps, if you want the file look for
  643. PMAIL21A.* that's version 2.1 but I remember seing a 2.2
  644. some time ago. I'll try to have my friend put it up for freq
  645. on his BBS (Node 1:240/20 that's in Quebec, Canada) I copied
  646. my TAPE to his system a few days ago but don't know if he
  647. has put the stuff up for downloads yet.
  648.  
  649. P.S. Moderator, sorry about the long <off topic> post but
  650. since a few people asked about this file I thought you
  651. wouldn't mind too much.
  652.  
  653.         Best regards,
  654.         Mark Ouellet.
  655.  
  656. --- ME2
  657.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  658.  * Tossed by SFToss v1.00b on 92/05/27  13:08:30
  659.  
  660. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  661.  
  662. Conference 4
  663. Date       05-26-92 19:13:22
  664. From       Mark Ouellet
  665. To         Dj Murdoch
  666. Subject    Re: Help - Reading Records At
  667.  
  668.  
  669.     On 22 May 92, you, Dj Murdoch, of 1:221/177.40 wrote...
  670.  
  671.  DM> Oops, I made a typo there - that should be 
  672.  DM> LongMul(Record_To_Get,Bytes_To_Read)
  673.  
  674. Correction noted AND SAVED, AS WAS THE PREVIOUS POST ;-)
  675.  
  676.  MO>> Thanks for the tip Dj,
  677.  MO>>         It does seem interresting allthough I never played
  678.  MO>> with Streams yet, thought they looked complicated, your
  679.  MO>> example made it look a lot simpler than I thought.
  680.  
  681.  DM> I think the manual makes them look unnecessarily complicated.  If you 
  682.  
  683.  DM> skip over the object registration and Put and Get, they're really no 
  684.  
  685.  DM> more complicated than any other binary file.
  686.  
  687. Thanks again Dj,
  688.         They do seem easy, your first post had me thinking
  689. so I took a look in the resident help to see wether they
  690. supported the same functions such as SEEKS and found out
  691. they do so it becomes even more interresting.
  692.  
  693.         Best regards,
  694.         Mark Ouellet.
  695.  
  696.  
  697. --- ME2
  698.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  699.  * Tossed by SFToss v1.00b on 92/05/27  13:08:30
  700.  
  701. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  702.  
  703. Conference 4
  704. Date       05-26-92 19:16:30
  705. From       Mark Ouellet
  706. To         Greg Smith
  707. Subject    Re: Soundblaster
  708.  
  709.  
  710.     On 21 May 92, you, Greg Smith, of 1:104/60.0 wrote...
  711.  
  712.  MO>>Yake a look at ATI's STEREO-F/X or better yet their VGA
  713.  MO>>Stereo-F/X which I got.
  714.  
  715.         Oops, thought I had fixed that "(T) Yake", evidently
  716. I forgot ;-)
  717.  
  718.  MO>>        VGA card, 1024x768x256
  719.  MO>>        Fully Adlib/SB Pro compatible
  720.  MO>>        BUS Mouse interface + 3 button mouse.
  721.  MO>>        ALL ON A SINGLE CARD, ALL IT LACKS IS THE CD-ROM
  722.  
  723.  GS> Sounds good, but considering that I've already got a SB Pro, serial
  724.  GS> mouse (and plenty of com ports), and a VGA.  It's not worth it for me.
  725.  GS> Anyways, do you have any info on programming the SB Pro's specific
  726.  GS> enhancements?
  727.  
  728. Well Greg,
  729.         I also had an SB and a VGA Wonder with BUS mouse but
  730. decided to upgrade to the 1Meg version of the ATI Stereo-F/X
  731. for the added graphics and audio possibilities. As for
  732. programming the enhancements, apart from the SPjr that came
  733. with the card I'm pretty much following every thread on SBs
  734. and Adlibs just as you are probably doing, hopeing for a
  735. good source. Also grabbing anything related such as PYTHON,
  736. TRAK-Blaster, BMaster (Which supports the F/Xs 44Khz
  737. sampling rate) etc...
  738.  
  739.         Best regards,
  740.         Mark Ouellet.
  741.  
  742.  
  743.  
  744. --- ME2
  745.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  746.  * Tossed by SFToss v1.00b on 92/05/27  13:08:30
  747.  
  748. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  749.  
  750. Conference 4
  751. Date       05-26-92 19:23:07
  752. From       Mark Ouellet
  753. To         Jud Mccranie
  754. Subject    Re: Why I Like Tp 5.5 Ide
  755.  
  756.  
  757.     On 21 May 92, you, Jud Mccranie, of 1:3645/10.0 wrote...
  758.  
  759.  PF>>> I'm not sure what you mean, there is a version greater than 6.0 ?
  760.  
  761.  JM> Yes, 5.5 is greater than 6.0!
  762.  
  763. Jud,
  764.         I'm getting tired of those "5.5 is better than 6.0"
  765. just as much as of the "6.0 is better than 5.5".
  766.  
  767.         None of it is helpfull, people with 6.0 think it is
  768. better and people with 5.5 think IT is better, the logic of
  769. it all is that someone who buys 5.5 because a 6.0 basher
  770. told him so might in fact have benefited from 6.0 or even
  771. liked it better, just as the opposite is possible.
  772.  
  773.         If people who have seen both products can't agree
  774. then there is an even chance the same will be true for
  775. future users.
  776.  
  777. So pushing one or the other doesn't help anyone.
  778.  
  779.         Best regards,
  780.         Mark Ouellet.
  781.  
  782.  
  783.  
  784. --- ME2
  785.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  786.  * Tossed by SFToss v1.00b on 92/05/27  13:08:30
  787.  
  788. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  789.  
  790. Conference 4
  791. Date       05-26-92 19:50:05
  792. From       Mark Ouellet
  793. To         jeroen pluimers
  794. Subject    Re: bug in TCollection
  795.  
  796.  
  797.     On 17 May 92, you, jeroen pluimers, of 2:281/521.0 wrote...
  798.  
  799.  JP> (fwd from compuserve)
  800.  JP> 
  801.  JP> #: 152141 S1/OOP and TVision
  802.  JP> 15-May-92  21:22:34
  803.  JP> Sb: #Collection Crash
  804.  JP> Fm: Ken Ross 73647,330
  805.  JP> To: All
  806.  JP> 
  807.  JP> The following program will crash when the collection fails to allocate
  808.  JP> enough memory to grow.  The colle
  809.  JP> ction's Error method is not called.
  810.  JP> I looked at the OWL source (don't have TV source) and sure enough, there
  811.  JP> is no check for allocation failure.  The problem is in SetLimit, which 
  812.  
  813.  JP> is
  814.  JP> virtual, so I guess I should override SetLimit.  Does anyone already 
  815.  
  816.  JP> have
  817.  JP> a fix or better solution?
  818.  JP> -Ken
  819.  JP> 
  820.  JP> {WARNING! THIS PROGRAM WILL CRASH YOUR SYSTEM}
  821.  JP> {$M 16384, 0, 98000}  {Start with 98K heap}
  822.  JP> 
  823.  JP> uses Objects;
  824.  JP> 
  825.  JP> function HeapFunc(Size: Word): Integer; far;
  826.  JP> begin
  827.  JP> if Size = 0 then HeapFunc := 2 else HeapFunc := 1;
  828.  JP> end;
  829.  
  830.  JP> begin
  831.  JP> HeapError := @HeapFunc;
  832.  
  833. jeroen,
  834.         This is due to the difference in working of TP 6.0
  835. and TP4W's OWL. In TP6 the HeapError can in deed be
  836. overriden BUT in OWL there allready is a VERY GOOD HeapError
  837. function which will release the safety-pool and return 2 for
  838. try again. The solution is override TP6's heaperror but not
  839. TP4W's.
  840.  
  841.         Best regards,
  842.         Mark Ouellet.
  843.  
  844.  
  845.  
  846. --- ME2
  847.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  848.  * Tossed by SFToss v1.00b on 92/05/27  13:08:31
  849.  
  850. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  851.  
  852. Conference 4
  853. Date       05-26-92 20:04:22
  854. From       Mark Ouellet
  855. To         Edward Kmett
  856. Subject    Re: SoundBlaster Control Unit Demo
  857.  
  858.  
  859.     On 22 May 92, you, Edward Kmett, of 1:120/144.0 wrote...
  860.  
  861.  EK> Uses Crt, AdLib;
  862.  < stuff deleted to save space >
  863.  
  864.  EK> O.K. That'll play a samll segment from Phantom of the Opera. I know it's 
  865.  
  866.  EK> not the most efficient code, but it works. I slapped it together a 
  867.  EK> little while ago. It demonstrates 2 voice at the same time. My Unit can 
  868.  
  869.  EK> control up to 9. I based it on that J. Lee document that has been posted 
  870.  
  871.  EK> recently, after hunting around on my own I stumbled across it. Does 
  872.  EK> anyone out there have DAC source? If so I'll neaten this up and merge it 
  873.  
  874.  EK> with that to build up a full-fledged presentable TP Unit. As this stands 
  875.  
  876.  EK> this doesn't support everything and it has poor documentation. Any 
  877.  EK> questions, just ask.
  878.  
  879. Thanks Edward,
  880.         made it through loud and clear this time.
  881.  
  882.         Best regards,
  883.         Mark Ouellet.
  884.  
  885.  
  886.  
  887. --- ME2
  888.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  889.  * Tossed by SFToss v1.00b on 92/05/27  13:08:31
  890.  
  891. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  892.  
  893. Conference 4
  894. Date       05-27-92 06:49:19
  895. From       Dj Murdoch
  896. To         Randall Smith
  897. Subject    Re: Borland, Os/2 2.0, And Yo
  898.  
  899.   >I would like to use Turbo Pascal 6.0 within OS/2 2.0. 
  900.  > But I consistently 
  901.  >run into the following problem when I use the internal debugger: When 
  902.  >stepping into a program with F8 (Step over) or F7 (Trace into) and then 
  903.  
  904.  
  905.  RS> David;  One of those uses VCPI the other uses DPMI. And 
  906.  RS> never the twain shall meet!
  907.  
  908.  I don't think the internal debugger uses VCPI.  It runs fine on an XT.  It
  909. does do some weird things with interrupt vectors; I'd guess those are what
  910. gets OS/2 mad at it.
  911.  
  912. --- Msg V3.2
  913.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  914.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  915.  
  916. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  917.  
  918. Conference 4
  919. Date       05-27-92 06:51:07
  920. From       Dj Murdoch
  921. To         David Masaki
  922. Subject    Re: packing bytes
  923.  
  924.   DJM> A Huffman code often puts 2 bytes into one.  If you use a fixed 
  925.  DJM> code, you won't need to store a dictionary.  If you want to play 
  926.  
  927.  DavidM> Isn't a "fixed code" itself a dictionary? 
  928.  
  929. Yes, but you can put the dictionary into the decoding program, you don't need
  930. to put it into the file that's being compressed, so it doesn't take up any
  931. space where it counts.
  932.  
  933. --- Msg V3.2
  934.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  935.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  936.  
  937. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  938.  
  939. Conference 4
  940. Date       05-27-92 06:55:00
  941. From       Dj Murdoch
  942. To         Joy Mukherjee
  943. Subject    Re: TPSQAPI
  944.  
  945.   JM> Does anyone know where in Zone 1, preferably out of Texas, 
  946.  JM> where I can get the Squish API for Turbo Pascal?  I have 
  947.  JM> tried Idiot Savant, but no go...  (1:247/128 I believe).  
  948.  JM> Thanks for the help...
  949.  
  950. John Giesbrecht just sent me a copy, and I'll hatch it to PDN Pascal.  So
  951. it'll be available tonight on 1:221/177, and will spread out from there.
  952.  
  953. --- Msg V3.2
  954.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  955.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  956.  
  957. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  958.  
  959. Conference 4
  960. Date       05-27-92 07:48:27
  961. From       Dj Murdoch
  962. To         Mike Copeland
  963. Subject    Re: Using blank constants
  964.  
  965.   MC>    I have found a curious situation with TP (version 5.5): 
  966.  MC> when I use part of a large constant of blanks, it doesn't 
  967.  MC> compare equal to a blank variable.  For example, I have a 
  968.  MC> large constant of 40 blanks, called B40.  If I use it to 
  969.  MC> compare to a 15-character variable, via Copy, I do not get 
  970.  MC> equality if the variable is all blanks:
  971.  
  972.  MC>   if Copy(B40,1,15) = W15 then
  973.  MC>     S1
  974.  MC>   else
  975.  MC>     S2
  976.  
  977.  MC>    In this case, S1 is never executed.
  978.  
  979. Could you show us your declarations?  The following program prints "equal",
  980. as you'd expect:
  981.  
  982.   const
  983.     B40 = '                                        ';
  984.   var
  985.     W15 : string[15];
  986.   begin
  987.     W15 := '               ';
  988.     if Copy(B40,1,15) = W15 then
  989.       writeln('equal')
  990.     else
  991.       writeln('not equal');
  992.   end.
  993.  
  994.  
  995.  
  996. --- Msg V3.2
  997.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  998.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  999.  
  1000. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1001.  
  1002. Conference 4
  1003. Date       05-27-92 07:52:19
  1004. From       Dj Murdoch
  1005. To         Erik Giberti
  1006. Subject    Re: Running Bat files from Pascal
  1007.  
  1008.   EG> > What if he doesn't have command.com in the root directory? Or worse, 
  1009.  
  1010.  EG> > what if he doesn't have command.com?
  1011.  
  1012.  EG> But as long as its in a path name it shouldnt matter... What about 4DOS?
  1013.  
  1014. No,
  1015.  
  1016. --- Msg V3.2
  1017.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1018.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  1019.  
  1020. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1021.  
  1022. Conference 4
  1023. Date       05-27-92 07:52:45
  1024. From       Dj Murdoch
  1025. To         Erik Giberti
  1026. Subject    Re: Running Bat files from Pascal
  1027.  
  1028.   EG> *** Quoting Trevor Carlsen to Gordon Tackett dated 05-19-92 ***
  1029.  EG> >  GT> EXEC('C:\COMMAND.COM','/cFILE.BAT');
  1030.  EG> > 
  1031.  EG> > What if he doesn't have command.com in the root directory? Or worse, 
  1032.  
  1033.  EG> > what if he doesn't have command.com?
  1034.  
  1035.  EG> But as long as its in a path name it shouldnt matter... What about 4DOS?
  1036.  
  1037. No, Exec won't search the path.  That's up to you to do yourself, using FSearch,
  1038. for example.
  1039.  
  1040. --- Msg V3.2
  1041.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1042.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  1043.  
  1044. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1045.  
  1046. Conference 4
  1047. Date       05-27-92 08:04:20
  1048. From       Dj Murdoch
  1049. To         Jud Mccranie
  1050. Subject    Re: Help - Reading Record
  1051.  
  1052.   JM> Well, DOS has an instruction for reading a sector, I believe (256
  1053.  JM> bytes, I think).  It reads the whole sector on one pass.  When you read
  1054.  JM> a file of byte, it seems to get you one bytes on each pass.  That is, it
  1055.  
  1056.  JM> reads in the sector, gives you the first byte, rotates and reads the
  1057.  JM> same sector again, gives you the second byte, etc.
  1058.  
  1059. Sectors are typically 512 bytes.  They're usually the smallest unit that the
  1060. disk hardware can read, though some newer hardware fakes bigger sectors to
  1061. get around DOS limitations on the number of sectors on a disk.
  1062.  
  1063. DOS buffers reads, so in the case you describe, it'll read 512 bytes, and
  1064. keep them in memory to satisfy your next 511 read requests.  Try running a
  1065. little program that reads a byte, waits a second, then reads another for a
  1066. while, and you shouldn't see your disk activity light come on very often.
  1067.  (Take your disk cache out first, or you'll almost never see it.)  DOS might
  1068. use different rules for floppy disks, where it's not sure if you've switched
  1069. disks between the reads.
  1070.  
  1071. Even though DOS does do buffering, for some reason it does it very badly,
  1072. so reading a byte at a time is quite slow.
  1073.  
  1074.  AC> I wonder if someone here as ever timed how long it takes to
  1075.  AC> read a nice sized file a character at a time verses a record,
  1076.  AC> line or some other number of characters???  I suspect that if
  1077.  AC> the buffer is set the same in both instances it should come out
  1078.  AC> pretty close?
  1079.  
  1080.  JM> No, reading a char at the time is VERY slow, even with a buffer.  Block
  1081.  JM> read is fast.
  1082.  
  1083. But TP can't do buffering on binary files.  That was introduced with streams;
  1084. a buffered stream is typically a bit faster than Blockread for medium sized
  1085. reads, and a lot faster for small reads.  On big reads there's not much differen
  1086. e.
  1087.  
  1088.  
  1089. --- Msg V3.2
  1090.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1091.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  1092.  
  1093. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1094.  
  1095. Conference 4
  1096. Date       05-27-92 08:12:17
  1097. From       Dj Murdoch
  1098. To         Matt Heck
  1099. Subject    Re: blah...
  1100.  
  1101.   DM> You will need to seek to the end of the original .EXE, but MH's
  1102.  DM> method of getting the original .EXE size is rather cumbersome.
  1103.  DM> The .EXE header always stores the length of the compiled .EXE
  1104.  DM> size, so you don't need to hard code it.  The compiler takes care
  1105.  DM> of it for you.
  1106.  DM>                     ------------------------------------
  1107.  
  1108.  MH>      Perhaps I forgot to mention this; the reason I used 
  1109.  MH> my method is that it allows you to PKLITE your program but 
  1110.  MH> leave the DATA (crammed onto the end) uncompressed. There 
  1111.  MH> are a few times that this is handy.
  1112.  
  1113. I think DM's method is better in that case.  PKLITE rewrites the header, so
  1114. it'll read the correct file length; your method with a hard coded file length
  1115. will mess up if someone expands the file, it changes somehow.
  1116.  
  1117. --- Msg V3.2
  1118.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1119.  * Tossed by SFToss v1.00b on 92/05/28  16:14:44
  1120.  
  1121. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1122.  
  1123. Conference 4
  1124. Date       05-27-92 04:23:55
  1125. From       Trevor Carlsen
  1126. To         Jud Mccranie
  1127. Subject    Re: Pascal Style #2
  1128.  
  1129.  
  1130.  
  1131.  TC> Your comments are closer to the mark than any of the others in
  1132.  TC> regards to Example C.  Without exception the criticism of that
  1133.  TC> method is the fact that it is harder to understand.  I agree -
  1134.  TC> but an important fact seems to be overlooked, that is, if it is
  1135.  TC> the best on all counts except readability then there should be
  1136.  TC> no problem, as that is one of the reasons we have comments. So -
  1137.  
  1138.  TC>   x := succ(ord(Y > 10);  { if y > 10 then x := 2 else x := 1;}
  1139.  
  1140.  JM> What about when the succ function can't be used?  Those
  1141.  JM> values of x that happened to be chosen were untypical.  When
  1142.  JM> you have to throw in a multiplication to get the right value
  1143.  JM> of x then it will slow down.
  1144.  
  1145. I was talking about the specific case.  The values you demonstrated were hardcod
  1146. d 1 and 2.  If multiplication becomes involved it would be senseless to use
  1147. that method unless there was some other very good reason for so doing.
  1148.  
  1149.  TC> Any code that may be hard to understand should be commented in
  1150.  TC> such a way so as to make it easier to understand.  In a team or
  1151.  TC> commercial environment that is an iron clad rule.  When two
  1152.  TC> coding methods have no difference in speed or size efficiency
  1153.  TC> *then* IMHO the more cryptic version should be discarded in
  1154.  TC> favour of the more readable.
  1155.  
  1156.  JM> These have little effect on size or efficiency.  *IF* you
  1157.  JM> have the special case above, then you can save 7 bytes.
  1158.  JM> Maybe you have that special case 5 times in a program,
  1159.  JM> savings of 35 bytes at the expense of making it hard to
  1160.  JM> read, understand, or modify.
  1161.  
  1162. As I said, *properly* commented and it ceases to be hard to read so the reasonin
  1163.  becomes null and void.
  1164.  
  1165.  JM> I grew up in the days of few comments.  Then I started
  1166.  JM> commenting more. Now I comment less because my programs are
  1167.  JM> "self-commenting", which is very advantageous.  Example B is
  1168.  JM> the most "self-commenting."  One thing criticised in K&P and
  1169.  JM> in a talk by Mike Covington are cases where the comments
  1170.  JM> DON'T actually match the code. I used to write
  1171.  
  1172.  JM> var EN : integer;   { employee number }
  1173.  JM> Now:
  1174.  JM> var EmployeeNumber : integer;
  1175.  JM> (with no descriptive comment)
  1176.  
  1177. Of course - and I agree.  But a lot of people allow that to virtually take
  1178. over their thinking and comments disappear.  
  1179.  
  1180. TeeCee
  1181.  
  1182. --- TC-ED   v2.01  
  1183.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1184.  * Tossed by SFToss v1.00b on 92/05/28  16:14:51
  1185.  
  1186. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1187.  
  1188. Conference 4
  1189. Date       05-28-92 07:46:08
  1190. From       Dj Murdoch
  1191. To         John Gohde
  1192. Subject    Re: A Virtuous Pascal ...
  1193.  
  1194.   JG> *Standard Pascal is very well suited to 70's ideas of structured
  1195.  
  1196.  JG> I would say that the 70's hardware was pretty primitive by todays
  1197.  JG> standards. So blame it on hardware, not structured programming!
  1198.  
  1199. ?? I don't get this.  There were much bigger languages than TP around in the
  1200. 70's - PL/I for example, is a huge language.  Pascal was small by design,
  1201. not because of hardware limitations.
  1202.  
  1203.  JG> My NEW Pascal will improve the modular concept by:
  1204.  
  1205.  JG>    (1)offering  a  standard  format  semi-compiled  version which
  1206.  JG>    could be compiled by any version (thereby, offering both speed
  1207.  JG>    and compatibility);
  1208.  
  1209. There's no reason to change the language to do this.  I'm not saying Borland
  1210. has done the best possible implementation of the language Turbo Pascal, but
  1211. I am saying that the language Turbo Pascal is a much better language than
  1212. Pascal.
  1213.  
  1214.  JG>    (2)Recognizing the reality of project management.
  1215.  JG>       a) very few users compile projects only once.
  1216.  JG>       b) do away with the need for uses statements
  1217.  JG>          Why am I wasting my  time hunting down units and tracing
  1218.  JG>          uses  statements when  that is  what computers  are for?
  1219.  JG>          Gee, Even I know that  a primitive database system based
  1220.  JG>          on the project concept would do the job very nicely.
  1221.  
  1222. If you do away with the Uses statement, you're going to have a mess on your
  1223. hands.  Many units declare identifiers with the same names; how's the compiler/l
  1224. nker supposed to know which ones you meant if you don't tell it?
  1225.  
  1226. One key to avoiding wasted time figuring out what needs to be Use'd is to
  1227. design the interface to the units carefully.  Make the purpose of each unit
  1228. crystal clear, so that if you've got a routine in mind, you can almost always
  1229. say "That must be in unit XXXX.".  
  1230.  
  1231. Another helper is an online help system like THELP or the one built-in to
  1232. TURBO.  I released a program called SCANHELP last year that builds a POPHELP
  1233. help database by scanning unit interface sections; I make sure that I keep
  1234. my help database up to date whenever I change any of my library of units.
  1235.  It now handles 28 units, with about 1300 help topics.
  1236.  
  1237.  JG> Further, Standard Pascal  is plain or simple NOT  bad. If it were
  1238.  JG> bad you would not be using Pascal!
  1239.  
  1240. I'm not using Pascal and never have.  Turbo Pascal is a closely related language
  1241.  with common roots, but it isn't Pascal.  There are some really fundamental
  1242. differences:
  1243.  
  1244.   Pascal is strongly typed.  TP lets you subvert the strong typing.
  1245.   Pascal has a weird model of files.  TP has a different, fairly natural 
  1246.     model.
  1247.   Pascal has very strict rules about what you can do with pointers.  TP lets 
  1248.  
  1249.     you do whatever you like with them.
  1250.   Etc.
  1251.  
  1252. These differences are what drive some teachers crazy - they want the discipline
  1253. of Pascal, which TP relaxes. 
  1254.  
  1255. --- Msg V3.2
  1256.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1257.  * Tossed by SFToss v1.00b on 92/05/29  20:27:33
  1258.  
  1259. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1260.  
  1261. Conference 4
  1262. Date       05-28-92 08:04:57
  1263. From       Dj Murdoch
  1264. To         Richard Nelson
  1265. Subject    Re: Message base formats (was: overlay f
  1266.  
  1267.   DM> probably also be straightforward, but I'd have to translate the API 
  1268.  DM> code to TP, unless someone else has already done so.  Do you know if 
  1269.  
  1270.  DM> someone has? 
  1271.  
  1272.  RN> Someone has.  I got the source (TPSQAPI1.*) directly from 
  1273.  RN> Scott Dudley's board (1:249/106, as I recall).  I have it 
  1274.  RN> available for FReq at 1:216/117.  I was thinking of 
  1275.  RN> writing an OOP version if I have time, but so far I 
  1276.  RN> haven't even had time to sort out the stuff in the archive.
  1277.  
  1278. John Giesbrecht kindly sent me a copy the other day, and I released it to
  1279. PDN for others.  It's a little confusing though - I've got Dudley's MSGAPI
  1280. in C, and it looks like quite a different API than what's in TPSQAPI - much
  1281. higher level.  I expect I'll be able to clear this up this summer though,
  1282. since I'm moving into Dudley's net in June. 
  1283.  
  1284. --- Msg V3.2
  1285.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1286.  * Tossed by SFToss v1.00b on 92/05/29  20:27:33
  1287.  
  1288. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1289.  
  1290. Conference 4
  1291. Date       05-28-92 08:11:17
  1292. From       Dj Murdoch
  1293. To         David G. Edwards
  1294. Subject    Re: Help - Reading Record
  1295.  
  1296.   DG> I've tried it, and there's a vast difference.  Char by 
  1297.  DG> char takes centuries. Record by record is better.  Better 
  1298.  DG> still is blockreading 64K at a time.
  1299.  
  1300. I did some timing the other day, and found that Streams can always match Blockre
  1301. d, and can sometimes do much better than it.  For reading blocks of 1K or
  1302. less, a TBufStream buffered stream is much faster than BlockRead.  For reading
  1303. big blocks, a TDOSStream unbuffered stream has performance just about identical
  1304. to BlockRead.
  1305.  
  1306. --- Msg V3.2
  1307.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1308.  * Tossed by SFToss v1.00b on 92/05/29  20:27:33
  1309.  
  1310. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1311.  
  1312. Conference 4
  1313. Date       05-28-92 08:31:02
  1314. From       Dj Murdoch
  1315. To         David G. Edwards
  1316. Subject    Re: TBufStream allocs
  1317.  
  1318.   DG> Does OBJECTS not do the same kind of heap checking that we 
  1319.  DG> all know and love?
  1320.  
  1321.  DG> This program will run okay under the IDE. I would expect 
  1322.  DG> it to bomb since heapmax is only 8000, and I ask the 
  1323.  DG> TBufStream object to alloc 8192 for its buffer.  I can set 
  1324.  DG> heapmax to less than 7500, and it will still seem to run okay.
  1325.  
  1326.  DG> {$M 16384, 0, 8000 } 
  1327.  
  1328. If you watch MemAvail as you step through your program, you'll see that it's
  1329. initially 8432 bytes, rather than 8000.  That's why your buffered stream can
  1330. be constructed properly.  
  1331.  
  1332. What I don't understand is why you don't get what you ask for; perhaps the
  1333. system routines sometimes need some heap, so they allocate some for themselves
  1334. without telling you.  Since the manual says the heap is guaranteed to never
  1335. be more than the max specified in the $M directive, I'd call this a bug, but
  1336. it might just be an omission in the manual.
  1337.  
  1338.  
  1339.  
  1340. --- Msg V3.2
  1341.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1342.  * Tossed by SFToss v1.00b on 92/05/29  20:27:34
  1343.  
  1344. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1345.  
  1346. Conference 4
  1347. Date       05-28-92 01:22:05
  1348. From       Trevor Carlsen
  1349. To         Jud Mccranie
  1350. Subject    Re: Help - Reading Record
  1351.  
  1352.  
  1353.  
  1354.  JM> No, there is a 255-byte header I want to discard at the front of the
  1355.  JM> file, then records of 331 characters.
  1356.  
  1357. Did you receive my solution?
  1358.  
  1359. TeeCee
  1360.  
  1361. --- TC-ED   v2.01  
  1362.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1363.  * Tossed by SFToss v1.00b on 92/05/29  20:27:43
  1364.  
  1365. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1366.  
  1367. Conference 4
  1368. Date       05-28-92 01:40:39
  1369. From       Trevor Carlsen
  1370. To         Mike Copeland
  1371. Subject    Using blank constants
  1372.  
  1373.  
  1374.  
  1375.  MC>    I have found a curious situation with TP (version 5.5): when I use 
  1376.  
  1377.  MC> part of a large constant of blanks, it doesn't compare equal to a 
  1378.  MC> blank variable.  For example, I have a large constant of 40 blanks, 
  1379.  MC> called B40.  If I use it to compare to a 15-character variable, via 
  1380.  MC> Copy, I do not get equality if the variable is all blanks:
  1381.  
  1382.  MC>   if Copy(B40,1,15) = W15 then
  1383.  MC>     S1
  1384.  MC>   else
  1385.  MC>     S2
  1386.  
  1387.  MC>    In this case, S1 is never executed.
  1388.  MC>    When I used the debugger, the copied value showed a value of 15 
  1389.  MC> #0's, rather than 15 #32's.
  1390.  MC>    Is there something special about Copy in such usage which prevents 
  1391.  
  1392.  MC> it from being used the way I wish?  (I really don't want to declare 40 
  1393.  
  1394.  MC> different constants to handle all situations...)
  1395.  
  1396. I'd like to see a short working demo of this.  I can't duplicate your results
  1397. in TP5, TP5.5 or TP6.  Is B40 a genuine constant or is it a typed constant?
  1398.  How is it initialised?
  1399.  
  1400. The following code works as you would expect:
  1401.  
  1402. const
  1403.   B40 = '                                         ';
  1404. var
  1405.   W15 : string;
  1406. begin
  1407.   W15 := '               ';
  1408.   if copy(B40,1,15) = W15 then
  1409.     writeln('This is executed')
  1410.   else
  1411.     writeln('This should not be executed');
  1412. end.
  1413.  
  1414. TeeCee
  1415.  
  1416.  
  1417. --- TC-ED   v2.01  
  1418.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1419.  * Tossed by SFToss v1.00b on 92/05/29  20:27:43
  1420.  
  1421. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1422.  
  1423. Conference 4
  1424. Date       05-28-92 01:48:59
  1425. From       Trevor Carlsen
  1426. To         Bruce Ruona
  1427. Subject    Pascal style #2
  1428.  
  1429.  
  1430.  
  1431.  TC> const
  1432.  TC>   MaxLong = $7fffffff;
  1433.  
  1434.  BR> just wondering, but Why do you redeclare this, when the already 
  1435.  BR> existing const MAXLONGINT serves the same purpose? unless you just 
  1436.  BR> want to save 3 key strokes every time you type this 8-)
  1437.  
  1438. Ignorance - plain and simple. (I *still* can't find it in the manual although
  1439. it is in the help system.)
  1440.  
  1441. Thanks.
  1442.  
  1443. TeeCee
  1444.  
  1445. --- TC-ED   v2.01  
  1446.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1447.  * Tossed by SFToss v1.00b on 92/05/29  20:27:43
  1448.  
  1449. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1450.  
  1451. Conference 4
  1452. Date       05-28-92 06:23:52
  1453. From       Trevor Carlsen
  1454. To         Chris Kelling
  1455. Subject    Re: A Virtuous Pascal ...
  1456.  
  1457.  
  1458.  
  1459.  CK> Most of what I had mentioned was a functiuon of VAX PASCAL,
  1460.  CK> which is implemented on VMS based machines.  None the less,
  1461.  CK> Inheiret is VPAS's interface for OOPs.  Creating a modual is
  1462.  CK> like creating a regualr program with out the header.  No
  1463.  CK> need for IMPLEMENT.  Iheiret also allos the program to take
  1464.  CK> on charecteristics of of a system service, not just a
  1465.  CK> process being run b a user.
  1466.  
  1467.  CK> I think the main thing is that we are comparing apples and
  1468.  CK> oranges.  I come from a programing environment that is
  1469.  CK> multi-user ladden, and am used to the services and features
  1470.  CK> of the larger machines.  I try to work w/ TP (the best
  1471.  CK> compiler for a PC pascal version), and get frustrated when I
  1472.  CK> try to do things that I can't or not sure on how to do what
  1473.  CK> takes two lined to do on VAX PASCAL.
  1474.  
  1475. I don't intend to enter into an argument on VMS v DOS.  There is no contest;
  1476. VMS wins hands down; and at the thousands of dollars it costs, there would
  1477. be something radically wrong if it didn't.
  1478.  
  1479. However I have used both products (VPAS and TP), albeit in a very limited
  1480. way, and have never come across anything that VPAS can do that TP cannot that
  1481. is unrelated to the operating system or hardware platform.  It may not be
  1482. done in exactly the same way but it can be done.
  1483.  
  1484. A great deal of the power of VP is directly related to the platform it runs
  1485. on and under and not to any actual improvement over other Pascals.  Take away
  1486. the VMS stuff and VP is just an ordinary Pascal implementation.
  1487.  
  1488. TeeCee
  1489.  
  1490. --- TC-ED   v2.01  
  1491.  * Origin: The Pilbara's Pascal Centre (+61 91 732930) (3:690/644)
  1492.  * Tossed by SFToss v1.00b on 92/05/29  20:27:43
  1493.  
  1494. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1495.  
  1496. Conference 4
  1497. Date       05-29-92 00:33:00
  1498. From       Norbert Igl
  1499. To         Steve Albright
  1500. Subject    screen input
  1501.  
  1502.  
  1503.  
  1504.  
  1505.  >    Does anyone know how to read a character from screen?
  1506.  >     (ie    gotoxy(x,y);[  Now read char from (x,y) off of the screen
  1507.  > to a variable?.
  1508.  
  1509.  Hi, Steve....
  1510.  
  1511.  uses CRT, DOS;
  1512.  [...]
  1513.  Function ScrReadChar(x,y:byte):char;
  1514.  var R:Registers;
  1515.      ox,oy : byte;
  1516.  begin
  1517.     ox := wherex;               { save cursor-position }
  1518.     oy := wherey;
  1519.     gotoxy(x,y);                { goto new position }
  1520.     R.AH := 8;                  { VBios: Get char & attr from cursor-position }
  1521.  
  1522.     R.BH := 0;                  { page-# = 0 }
  1523.     INTR($10,R);                { call Video-Bios }
  1524.     ScrReadChar := Char(R.AL);  { here we are (:-) }
  1525.                                 { ! R.AH holds the attribute of this char ! }
  1526.  
  1527.     gotoxy(ox,oy)               { restore cursor-position }
  1528.  end;
  1529.  
  1530.     Bye from Germany, Norbert
  1531.  
  1532. ---
  1533.  * Origin: May the source be with you... (2:241/5300.3)
  1534.  * Tossed by SFToss v1.00b on 92/05/30  07:24:17
  1535.  
  1536. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1537.  
  1538. Conference 4
  1539. Date       05-29-92 01:18:00
  1540. From       Norbert Igl
  1541. To         Stevo Wierengo
  1542. Subject    Detecting ANSI ?
  1543.  
  1544.  
  1545.  
  1546.  
  1547.  >    >        int 2f <<<<<<<
  1548.  
  1549.   hmmm, [BLUSH], right, must read:  $2F !
  1550.  
  1551.  > This would not compile for some reason on my computer, using TP6.
  1552.  
  1553.   of course not...(:-))
  1554.  
  1555.  > Function AnsiSysInstalled: boolean;
  1556.  > var
  1557.  >   _AX : word;
  1558.  >   Regs: Registers;
  1559.  > begin
  1560.  >   Regs.AX := $1a00;
  1561.  >   Intr(2,Regs);
  1562.          =^= ... OH NO, 2F is the multiplex-interrupt !!!
  1563.  >   _Ax := Regs.AX;
  1564.  >   ANSISysInstalled := Lo(_AX) = $FF
  1565.  > end;
  1566.  
  1567.   BTW... won't even work  with $2F this way, because Turbo's INTR()
  1568.   has problems with the $2F function!
  1569.  
  1570.   !  Use ASM...END in TP6 ( or INLINE() for older versions !)
  1571.  
  1572.   Bye from Germany, Norbert
  1573.  
  1574.  
  1575.  
  1576.  > Stevo
  1577.  >  * JABBER v1.1 * Freedom defined is freedom denied.
  1578.  
  1579.  > --- Maximus 2.00
  1580.  >  * Origin: Rochester Lab of BCS :HST/DS: (716)381-8538 (1:260/210)
  1581.  
  1582. ---
  1583.  * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
  1584.  * Tossed by SFToss v1.00b on 92/05/30  07:24:17
  1585.  
  1586. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1587.  
  1588. Conference 4
  1589. Date       05-29-92 08:13:36
  1590. From       Dj Murdoch
  1591. To         Greg Smith
  1592. Subject    Re: Swapping To Nowhere
  1593.  
  1594.   GS> I see not SetMemTop procedure in the TP 6.0 manuals.  Could you post
  1595.  GS> one?
  1596.  
  1597. It's only in the READ.ME and online help - a late addition.
  1598.  
  1599. --- Msg V3.2
  1600.  * Origin: Murdoch's_Point  - -   (1:221/177.40)
  1601.  * Tossed by SFToss v1.00b on 92/05/30  07:24:25
  1602.  
  1603. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1604.  
  1605. Conference 4
  1606. Date       05-29-92 19:34:31
  1607. From       Mark Ouellet
  1608. To         Gordon Tackett
  1609. Subject    Re: Multiuser databases
  1610.  
  1611.  
  1612.     On 22 May 92, you, Gordon Tackett, of 1:352/777.42 wrote...
  1613.  
  1614.  GT> Thanks for the effort.
  1615.  No problem, hope you saw my other message about this.
  1616.  
  1617.  GT> I was just noticing your name....Are you related to Jo Ouellet in 
  1618.  GT> Portland, Or.
  1619.  
  1620. Gordon,
  1621.         I really don't know, you probably know there are two
  1622. distinct way of writing it, Ouellet and Ouellette, if Jo
  1623. uses the former then there is a better than good chance we
  1624. are related in some way. I even found out through a collegue
  1625. who did his own genealogical tree that we were related, we
  1626. have a common ancestor and he's a Thibault. He is about to
  1627. publish the fruit of his research, probably a small, 300-400
  1628. page book.
  1629.  
  1630.         Best regards,
  1631.         Mark Ouellet.
  1632.  
  1633.  
  1634.  
  1635. --- ME2
  1636.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1637.  * Tossed by SFToss v1.00b on 92/05/30  16:03:42
  1638.  
  1639. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1640.  
  1641. Conference 4
  1642. Date       05-29-92 19:40:32
  1643. From       Mark Ouellet
  1644. To         Ken Burrows
  1645. Subject    Re: Help - Reading Records At
  1646.  
  1647.  
  1648.     On 22 May 92, you, Ken Burrows, of 1:249/201.21 wrote...
  1649.  
  1650.  KB> That was my misunderstanding. I was under the impression, each record 
  1651.  
  1652.  KB> consited of 581 bytes and he wanted to access partial records. I cannot 
  1653.  
  1654.  KB> recall if he specifically said it was DBF type of file. But, I suppose I 
  1655.  
  1656.  KB> should have known that. After all, Jud has been discussing his database 
  1657.  
  1658.  KB> for quite some time now.
  1659.  
  1660.         It is pretty easy to make a bad assumption on these
  1661. echo. Hell with what we have to go on some times to answer
  1662. those questions it's allmost impossible to know what they
  1663. want. In fact I might be wrong and Jud might actually be
  1664. looking for exactly what you offered. ;-)
  1665.  
  1666.  KB> I'm aware of that. I use the header data to get the starting offset and 
  1667.  
  1668.  KB> the number of records as well. 
  1669.  KB> 
  1670.  KB> Reset(f,1);
  1671.  KB> Seek(F,DataStart+ (RecordNumber - 1) * SizeOf(DataRecord));
  1672.  
  1673. Ken,
  1674.         Sorry I missed that part, assumed you opened the
  1675. file with the record's actual length which would have made
  1676. sens if the data to be droped was at the head of every
  1677. record and the database itself had no header.
  1678.  
  1679.         BTW hope you got my message about not being able to
  1680. reply to your Netmail message. I allready had trouble
  1681. connecting with ANY ZONE 3 nodes, hope I'm not develloping
  1682. the same problem with other zones.
  1683.  
  1684.         Best regards,
  1685.         Mark Ouellet.
  1686.  
  1687.  
  1688.  
  1689. --- ME2
  1690.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1691.  * Tossed by SFToss v1.00b on 92/05/30  16:03:42
  1692.  
  1693. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1694.  
  1695. Conference 4
  1696. Date       05-29-92 19:47:53
  1697. From       Mark Ouellet
  1698. To         David Masaki
  1699. Subject    Re: Compressing Binary Sorted Trees
  1700.  
  1701.  
  1702.     On 23 May 92, you, David Masaki, of 1:345/27.0 wrote...
  1703.  
  1704.  DM> Does anyone know the best way to compress a binary sorted tree?  I was 
  1705.  
  1706.  DM> thinking of outputing the inorder traversal to an array then rebuilding 
  1707.  
  1708.  DM> the tree, but it seems like a waste to have to allocate that much 
  1709.  DM> memory.  It does seem to be the easiest way.  Does anyone have code for 
  1710.  
  1711.  DM> another technique that just messes with the pointers? 
  1712.  
  1713. David,
  1714.         One problem with what you had in mind is that if you
  1715. are using a PLAIN binary tree and not the BALANCED or AVL
  1716. tree or even a B+Tree then rebuilding from a sorted list
  1717. will not produce a TREE but rather a linked list which will
  1718. lose all the speed binary trees give you to start with.
  1719.  
  1720.         If you think of it, suppose you allways alocate to
  1721. the left child when the value is greater than the current
  1722. node then since you will be dealing with ever increasing
  1723. values, you will have a tree that has only LEFT NODES
  1724. alocated.
  1725.  
  1726.         Of course if you are dealing with B+Trees or AVL
  1727. tress then the problem does not occur since they will
  1728. rebalance on every new insertion into the tree.
  1729.  
  1730.         In any case never insert into a "plain" binary tree
  1731. from a SORTED list.
  1732.  
  1733.         Best regards,
  1734.         Mark Ouellet.
  1735.  
  1736.  
  1737.  
  1738. --- ME2
  1739.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1740.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1741.  
  1742. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1743.  
  1744. Conference 4
  1745. Date       05-29-92 20:13:00
  1746. From       Mark Ouellet
  1747. To         Jud Mccranie
  1748. Subject    Re: Turbo 6
  1749.  
  1750.  
  1751.     On 23 May 92, you, Jud Mccranie, of 1:3645/10.0 wrote...
  1752.  
  1753.  PR>>   I was looking at the message list on here and it seems there
  1754.  PR>>   is a TURBO 6.0.  Right now I have TURBO 5.0, would it be
  1755.  PR>>  worth it to buy TURBO 6.0. What are the improvements?
  1756.  
  1757.  JM> A significant minority of us will say that 6.0 is not worth it.  I have
  1758.  JM> all verisions 2.0 - 6.0, but I primarily use 5.5.  6.0 has some nice
  1759.  JM> improvements, but they botched MANY things in 6.0.  There was a lot of
  1760.  JM> discussion of this a few months ago, and I don't want to stir things up
  1761.  
  1762.                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  1763.  JM> again.
  1764.      ^^^^^^
  1765.  
  1766. Jud,
  1767.         You just did, why don't you stick to what you know
  1768. best and that is what YOU like about 5.5 and let the 6.0
  1769. users tell him what THEY like about 6.0 and he is probably
  1770. old enough to decide on his own about the rest.
  1771.  
  1772.         If you really want to help these guys then don't add
  1773. comments such as you do about 6.0, let them decide on their
  1774. own.
  1775.  
  1776.         Best regards,
  1777.         Mark Ouellet.
  1778.  
  1779.  
  1780.  
  1781. --- ME2
  1782.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1783.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1784.  
  1785. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1786.  
  1787. Conference 4
  1788. Date       05-29-92 20:21:32
  1789. From       Mark Ouellet
  1790. To         Peter Kling
  1791. Subject    Re: Question, Compression
  1792.  
  1793.  
  1794.     On 23 May 92, you, Peter Kling, of 1:267/169.0 wrote...
  1795.  
  1796.  >> Too bad PkZip version 2.0 has been out for the longest time already,
  1797.  PK> To bad Pkzip V2.0 is not out, that is a hacked version.   Please check
  1798.  PK> your source /delete it and start over.
  1799.  
  1800. Peter,
  1801.         Then why is it advertized in PC-Magazine ???? and
  1802. why is 2.01 in beta testing (According to MY sources)
  1803.  
  1804.         Best regards,
  1805.         Mark Ouellet.
  1806.  
  1807.  
  1808.  
  1809. --- ME2
  1810.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1811.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1812.  
  1813. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1814.  
  1815. Conference 4
  1816. Date       05-29-92 20:30:30
  1817. From       Mark Ouellet
  1818. To         Kevin Pieckiel
  1819. Subject    Re: Turbo Pascal-Just A Name?
  1820.  
  1821.  
  1822.     On 25 May 92, you, Kevin Pieckiel, of 1:275/99.0 wrote...
  1823.  
  1824.  KP> Why is it then that BASIC is in all caps??  Pascal and Turbo Pascal are 
  1825.  
  1826.  KP> just
  1827.  KP> names, but isn't BASIC just a name as well??
  1828.  
  1829. Kevin,
  1830.         BASIC is a special case... It's also an acronym,
  1831. just like COBOL or APL, acronyms are allways in uppercase.
  1832.  
  1833.         Best regards,
  1834.         Mark Ouellet.
  1835.  
  1836.  
  1837.  
  1838. --- ME2
  1839.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1840.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1841.  
  1842. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1843.  
  1844. Conference 4
  1845. Date       05-29-92 20:39:12
  1846. From       Mark Ouellet
  1847. To         James Cook
  1848. Subject    Re: RE: MCGA TUTORIALS
  1849.  
  1850.  
  1851.     On 24 May 92, you, James Cook, of 1:387/307.0 wrote...
  1852.  
  1853.  JC> Craig,
  1854.  JC> I think my next couple tutorials will deal with sprite graphics 
  1855.  JC> without using a mask and animation.  Stay tuned...
  1856.  
  1857. James,
  1858.         No problem, my monitor doesn't have a knob ;-)
  1859.  
  1860.         Best regards,
  1861.         Mark Ouellet.
  1862.  
  1863.  
  1864.  
  1865. --- ME2
  1866.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1867.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1868.  
  1869. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1870.  
  1871. Conference 4
  1872. Date       05-29-92 20:54:11
  1873. From       Mark Ouellet
  1874. To         Dawn Prish
  1875. Subject    Re: $80?
  1876.  
  1877.  
  1878.     On 22 May 92, you, Dawn Prish, of 2:403/444.0 wrote...
  1879.  
  1880.  JM>> SP> A list.. Welp, I M searching 4 1 4 about a year or so..
  1881.  JM>>                    ^^^           ^^^^^
  1882.  
  1883.  JM>>     Not to be too annoying (TC? Don't slay me here), but
  1884.  JM>>isn't
  1885.  JM>>     the official language of this echo English?
  1886.  DP> I talk Eng., these r abbriviations, makes the msg "Shorter".. Want 2 
  1887.  
  1888.  DP> make  something of it? ;-)
  1889.  
  1890. Dawn,
  1891.         Wrong, these make D messages "Harder" 2 read for us.
  1892.  
  1893.         And it can get 2 a . where it is anoying. If U R
  1894. tired of writing, perhaps U should reply l8r when U R - so
  1895. tired.
  1896.  
  1897.         Get my . ;-)
  1898.         Best regards,
  1899.         Mark Ouellet.
  1900.  
  1901. P.S. I'm only saying this for your own good, heck I allmost
  1902. passed over your messages from being tired of having to
  1903. interpret them twice, once to english and then to decide
  1904. what you meant.
  1905.  
  1906. --- ME2
  1907.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1908.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1909.  
  1910. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1911.  
  1912. Conference 4
  1913. Date       05-29-92 21:09:47
  1914. From       Mark Ouellet
  1915. To         Brad Roberts
  1916. Subject    Re: SayGet Unit #2/8
  1917.  
  1918.  
  1919. Brad,
  1920.         Only parts 1 & 2 made it through the net, you might
  1921. want to change the Subject and put the numbers at the start
  1922. so that any mailer that doesn't check the FULL subject line
  1923. does not discard them as duplicates.
  1924.  
  1925.         Instead of "Such & Such Unit #1/8" make it "#1/8
  1926. Such & Such Unit"
  1927.  
  1928.         Best regards,
  1929.         Mark Ouellet.
  1930.  
  1931.  
  1932.  
  1933. --- ME2
  1934.  * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
  1935.  * Tossed by SFToss v1.00b on 92/05/30  16:03:43
  1936.